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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 



20020059079 Negri 5-2002 

"QoS for Distributed Object Computing Middleware — Fact or Fiction?" Schmidt, 5/1997 

"Quality of Service Aware Distributed Object Systems," Koistinen et al. , 5/1999 
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(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all obviousness rejections set 
forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth 
in section 102 of this title, if the differences between the subject matter sought to be patented and the prior 
art are such that the subject matter as a whole would have been obvious at the time the invention was made 
to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

4. Claims 1-14, 17-30, 33-46, and 49 are rejected under 35 U.S.C. 103(a) as being unpatentable over Negri 
(US 2002/0059079) in view of Schmidt ("QoS for Distributed Object Computing Middleware - Fact or Fiction?," 
May 22nd, 1997, Columbia University). 

Per claim 1 : 
Negri discloses: 

-a component specification element that specifies components (i.e. "Defines the principal components in a service. 
These include the software services and related physical elements that combine to deliver the service," 0048); 
Negri does not explicitly disclose that the components are reusable components. However, Schmidt discloses using 
a reusable component was known at the time the invention was made to "reduce development effort and increase 
software quality (page 1, first paragraph)." 

Therefore, it would have been obvious for one skilled in the art of the pertinent art to modify Negri's disclosed 
system to incorporate the teachings of Schmidt. The modification would be obvious because one skilled in the art 
would be motivated to reuse the existing components for fast and flexible application development, 
-a control flow specification element that specifies control flows (i.e. "The business process involves the flow of 
data and control through a complex arrangement of these components. . .eService management must understand this 
flow of data," 0046; 0049, "the relationship graph defines the actual topology of the model. Components can depend 
on each other," 0050) 
Negri teaches 
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- a data flow specification element that specifies data flows (i.e. "The business process involves the flow of data and 
control through a complex arrangement of these components. . .eService management must understand this flow of 
data," 0046; 0049; "the relationship graph defines the actual topology of the model. Components can depend on 
each other," 0050); 

-a resource specification element that specifies resources (i.e. "Components can depend on each other.. .but they can 
also share common resources," 0050, 0051, 0060, 0063); 

-a quality of service specification derivation element, the quality of service specification derivation element (i.e. 

"deriving an e-service management strategy based on said business process specification. . .ensuring the service 

quality of said e-service," claim 1; 0036; 0050; 0057; 0063) having for output an application model in combination 

with a quality of service specification derived by implication from relations between the components, the control 

flows, the data flows and the resources (i.e. "a service delivery model. . .to assure the customer experience at the 

point of service delivery," 0063; "An eService model... Defines the principal components in a service... Components 

are modeled by service delivery function. . .Process and responsibilities may be defined by function. . .Establishes 

implicit and explicit relationships. . .share common resources, exchange data with each other, collect common 

statistics, and work together in complex flows of control," 0047-0050; 0046); 

-wherein the quality of service specification derivation element tests the components and 

the relations between the components to derive the quality of service specification (i.e. 0056; 0060). 

Negri does not explicitly disclose that the quality of service specification (the service delivery model) is 
made available to a runtime engine for deployment as a runtime contract in a runtime processing environment. 
However, it would have been obvious for a person having ordinary skill in the pertinent art at the time the invention 
was made to modify Negri's disclosed system to derive a runtime contract from the service delivery model 
(described at build time) at the point of service delivery (runtime) to enforce the service delivery specification in the 
model. The service delivery model in Negri would help "ensuring the quality of eService delivery (0023)" when 
deployed at runtime. 



Per claim 2: 
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The rejection of claim 1 is incorporated, and further, Negri discloses a runtime engine for deploying said runtime 
contract (i.e. "Service Level Agreements (SLA)," 0014; "a WebLogic BeX can be deployed at any site built upon 
BEA's WebLogic application server, 0058; claim 1; 0036; 0050; 0057; 0063) as claimed. 

Per claim 3: 

Negri does not explicitly disclose that said runtime contract comprises a messaging requirement contract. Negri 
discloses a service level agreement (SLA) that specify the levels of service (0014) and a Service level management 
tool that measures service delivery (0036). Therefore, it would have been obvious for a person having ordinary skill 
in the pertinent art at the time the invention was made to modify Negri's disclosed system to include a messaging 
requirement in the service delivery contract to help "ensuring the quality of eService delivery (0023)." 

Per claim 4: 

Negri does not explicitly disclose that said runtime contract comprises a transactionality requirement contract. 
Negri discloses a service level agreement (SLA) that specify the levels of service (0014) and a Service level 
management tool that measures service delivery (0036). Therefore, it would have been obvious for a person having 
ordinary skill in the pertinent art at the time the invention was made to modify Negri's disclosed system to include a 
transactionality requirement in the service delivery contract to help "ensuring the quality of eService delivery 
(0023)." 

Per claim 5: 

Negri does not explicitly disclose that said runtime contract comprises a security requirement. Negri discloses a 
service level agreement (SLA) that specify the levels of service (0014) and a Service level management tool that 
measures service delivery (0036). Therefore, it would have been obvious for a person having ordinary skill in the 
pertinent art at the time the invention was made to modify Negri's disclosed system to include a security 
requirement in the service delivery contract to help "ensuring the quality of eService delivery (0023)." 
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Per claim 6: 

Negri does not explicitly disclose that said runtime contract comprises a recoverability requirement. Negri discloses 
a service level agreement (SLA) that specify the levels of service (0014) and a Service level management tool that 
measures service delivery (0036). Therefore, it would have been obvious for a person having ordinary skill in the 
pertinent art at the time the invention was made to modify Negri's disclosed system to include a recoverability 
requirement in the service delivery contract to help "ensuring the quality of eService delivery (0023)." 

Per claim 7: 

Negri does not explicitly disclose that said runtime contract comprises a completion requirement. Negri discloses a 
service level agreement (SLA) that specify the levels of service (0014) and a Service level management tool that 
measures service delivery (0036). Therefore, it would have been obvious for a person having ordinary skill in the 
pertinent art at the time the invention was made to modify Negri's disclosed system to include a completion 
requirement in the service delivery contract to help "ensuring the quality of eService delivery (0023)." 

Per claim 8: 

Negri does not explicitly disclose that said runtime contract comprises a completion requirement contract. Negri 
discloses a service level agreement (SLA) that specify the levels of service (0014) and a Service level management 
tool that measures service delivery (0036). Therefore, it would have been obvious for a person having ordinary skill 
in the pertinent art at the time the invention was made to modify Negri's disclosed system to include a completion 
requirement contract specifying transactional behavior in the service delivery contract to help "ensuring the quality 
of eService delivery (0023)." 

Per claim 9: 

Negri does not explicitly disclose that said runtime contract comprises a completion requirement contract specifying 
compensation behavior. Negri discloses a service level agreement (SLA) that specify the levels of service (0014) 
and a Service level management tool that measures service delivery (0036). Therefore, it would have been obvious 
for a person having ordinary skill in the pertinent art at the time the invention was made to modify Negri's disclosed 
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system to include a completion requirement contract specifying compensation behavior in the service delivery 
contract to help "ensuring the quality of eService delivery (0023)." 

Per claim 10: 

Negri does not explicitly disclose that said runtime contract comprises at least one of a reliability, availability and 
serviceability requirement. Negri discloses a service level agreement (SLA) that specify the levels of service (0014) 
and a Service level management tool that measures service delivery (0036). Therefore, it would have been obvious 
for a person having ordinary skill in the pertinent art at the time the invention was made to modify Negri's disclosed 
system to include at least one of a reliability, availability and serviceability requirement in the service delivery 
contract to help "ensuring the quality of eService delivery (0023)." 

Per claim 1 1 : 

The rejection of claim 1 is incorporated, and further, Negri discloses 

a quality of delivery requirement contract (i.e. "Service Level Agreements (SLA)," 0014; "quality of eService 
delivery," 0023) as claimed. 

Per claim 12: 

Negri does not explicitly disclose that said runtime contract comprises at least one of a priority requirement and a 
response goal requirement. Negri discloses a service level agreement (SLA) that specify the levels of service (0014) 
and a Service level management tool that measures service delivery (0036). Therefore, it would have been obvious 
for a person having ordinary skill in the pertinent art at the time the invention was made to modify Negri's disclosed 
system to include at least one of a priority requirement and a response goal requirement in the service delivery 
contract to help "ensuring the quality of eService delivery (0023)." 

Per claim 13: 

Negri does not explicitly disclose that said runtime contract comprises a performance requirement. Negri discloses a 
service level agreement (SLA) that specify the levels of service (0014) and a Service level management tool that 



Application/Control Number: 09/808,50 1 Page 8 

Art Unit: 2193 

measures service delivery (0036). Therefore, it would have been obvious for a person having ordinary skill in the 
pertinent art at the time the invention was made to modify Negri's disclosed system to include a performance 
requirement in the service delivery contract to help "ensuring the quality of eService delivery (0023)." 

Per claim 14: 

The rejection of claim 1 is incorporated, and further, Negri discloses the quality of service specification is stored in a 
repository (i.e. 0051). 

Per claim 17: 

The rejection of claim 1 is incorporated, and further, Negri discloses a quality of service specification is stored in a 
modeling language (i.e. "eService modeling," 0044) as claimed. 

Per claims 18-30 and 33, they are the method versions of claims 1, 2, 4-14 and 17, respectively, and are 
rejected for the same reasons set forth in connection with the rejection of claims 1, 2, 4-14 and 17 above. 

Per claims 34-46 and 49, they are the computer program product versions of claims 18-30 and 33, 
respectively and are rejected for the same reasons set forth in connection with the rejection of claims 18-30 and 33 
above. 

5. Claims 15, 16, 3 1, 32, 47, and 48 are rejected under 35 U.S.C. 103(a) as being unpatentable over Negri (US 

2002/0059079) in view of Schmidt ("QoS for Distributed Object Computing Middleware - Fact or Fiction?," May 
22nd, 1997, Columbia University), further in view of Koistinen et al. ("Quality of Service Aware Distributed Object 
Systems," 5/1999) hereinafter referred to as "Koistinen." 

Per claim 16: 

The rejection of claim 1 is incorporated, and further, Negri and Schmidt do not explicitly teach that the quality of 
service specification is stored in XML. However, Koistinen teaches that storing a quality of service specification in a 
tagged markup language such as XML was known in the pertinent art, at the time applicant's invention was made, 
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"so that it can be understood readily by humans and parsed easily (pg 9, Implementation section)" such as that 
disclosed in Koistinen. It would have been obvious for one skilled in the art of the pertinent art to modify Negri and 
Schmidt's disclosed system to use XML. The modification would be obvious because one skilled in the art would be 
motivated to provide readability and ease parsing as taught by Koistinen (pg 9, Implementation section). 

Per claim 32, it is the method version of claim 16, respectively, and is rejected for the same reasons set 
forth in connection with the rejection of claim 16 above. 

Per claim 48, it is the computer program version of claim 16, respectively, and is rejected for the same 
reasons set forth in connection with the rejection of claim 16 above. 

Per claim 15, this claim is broader version of the claimed system discussed in claim 16 wherein all claim 
limitations also have been addressed and/or covered in cited areas as set forth the above. XML in claim 16 is a 
tagged markup language. Therefore, accordingly, see the rejection of claim 16 above. 

Per claim 3 1, it is the method version of claim 15, respectively, and is rejected for the same reasons set 
forth in connection with the rejection of claim 15 above. 

Per claim 47, it is the computer program version of claim 15, respectively, and is rejected for the same 
reasons set forth in connection with the rejection of claim 15 above. 

(10) Response to Argument 

l)The appellant states that Negri is directed to deriving an e-service management strategy- 
based on a business process model. . .a BeX is developed independent of a specific model and 
utilizes relationships within an e-service model to analyze the impact of related components, and 
includes a local processing engine. In contrast, in the instant invention, the runtime contract 
specifies services that are required to be provided by a target environment. It would have 
not been obvious to modify Negri's disclosed system to derive a runtime contract from a service 
delivery model (brief, page 5-6). 
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In response, Negri discloses "deriving an e-service management strategy based on said 
business process specification. . .ensuring the service quality of said e-service (claim 1; 0036; 
0050; 0057; 0063)." The specification is defined using the eService model. Negri's eService 
management (eSM) uses the eService model and BeXs to "assure the customer experience at the 
point of service delivery (0063)." The eService model specifies the components in a service, 
process, responsibilities (i.e. 0048; 0049) and establishes implicit and explicit relationships of the 
components (i.e. 0050; 0051), their dependences (i.e. 0050), resources sharing (0050), data and 
control flows among the components (0050). The eSM provides a service level agreement 
(requirement/contract) from the model specification defining Qos (Quality of Service) and BeX 
that monitors/analyzes the behavior of components, processes, and services to assure the Qos at 
the point of service delivery (runtime) (0063; 0040; 0044) . Therefore, the eSM fulfills analyzing 
the service delivery process and rapid deployment using a combination of eService modeling and 
a BeX to "deliver on quality of service commitments with confidence (0044)." Although Negri 
does not explicitly state that the Qos specification constructed from the eSM is made available to 
a runtime engine for deployment as a runtime contract in a runtime processing environment, the 
service delivery model specification defining how the business process should be executed at 
runtime in combination of BeXs control (0063) would be later sent to a target (customers) 
processor for execution (runtime engine) to realize the Qos specified in the eService model. The 
Qos specification in the model becomes the SLA (service level agreement) which is the runtime 
contract when executed at the target. Therefore, it would have been obvious for a person having 
ordinary skill in the pertinent art at the time the invention was made to modify Negri's disclosed 
system to derive a runtime contract from the service delivery model at the point of service 
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delivery to enforce the quality of service specified in the model. The derived eService 
management strategy by using the eService delivery model and BeXs in Negri would help 
"ensuring the quality of eService delivery (0023)" when deployed at runtime. 

2) Negri does not teach the derivation of a runtime contract from a quality of service 
specification that is derived by a quality of service specification derivation element that tests 
components and relations between the components or for that matter the use of runtime 
contracts. While Negri discloses the use of BeXs, Negri BeXs do not test components and 
relations between components to derive a quality of service specification, the BeXs do not create 
a quality of service specification. As such, Negri does not teach a quality of service specification 
derivation element that test components and relations between components to derive a quality of 
service specification (brief, 6). 

In response, Negri's "eSM manages the service resources with an exclusive focus on 
ensuring peak performance of eBusiness services.... All monitoring, analysis and control is done 
in context of the service (0040)" by using BeXs that observe, learn,. . .optimize, and control the 
entire functional model in the eService model (0056). The BeX "utilizes the relationships within 
the eService model to analyze the impact of related components" and "leverages the 
relationships in the model to analyze the effect of a component on eService delivery (0057)" to 
replicate service delivery best practices and focus on eService delivery more efficiently (0059). 
Therefore, the eSM tests the components and relationships among them in the eService model by 
using BeXs to derive the "e-service management strategy based on the business process 
specification "aiming at ensuring the quality of eService delivery (0023; page 5, claim 1)" and 
assuring "the customer experience at the point of service delivery (0063)." 
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3) Negri does not suggest a quality of service specification derivation element that 
also derives a quality of service specification by implication from relations between components, 
control flows, data flows, and resources. Negri is merely directed to a service level management 
tool that measures service delivery. Negri merely discloses that an e-service model establishes 
implicit and explicit relationships between components that defines an actual topology of the 
model (brief, 6-7). 

In response, the instant specification does not describe how the implicit relationship is 
specifically established. The specification, in page 14 states that the QOS specification derivation 
engine derives the implicit QOS requirements for the model from the relationships within the 
specifications for the composed model. Negri clearly discloses that the components relationships 
can be established implicitly as well as explicitly (0050). That is, in Negri, the dependencies 
among components, resource sharing, exchanging data with each other and working together in 
complex flows of control can be established implicitly (0050). For example, the eService 
delivery process is organized into a dependency graph of business applications with their 
operation relationships, thus the Customer Order Entry system depends on an implicit access to 
the Customer Database etc and the eSM recognizes and understands these dependencies whether 
they are within a physical organization or across a virtual enterprise (0051). 

4) Dependent claims 8, 24, and 40: The appellant states that Negri does not disclose a 
runtime contract that is a completion requirement contract that specifies transactional behavior 
(brief 7-8). 
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In response, the instant specification does not describe any inventive implementation of 
such a completion/transactional requirement. Furthermore, the eService model in Negri can 
define any requirement that can ensure the quality of eService delivery such as 
transactional/completion requirement so that the eService can be rapidly and flexibly deployed 
(0043) based on such a requirement defined in the model. For example, the model would specify 
such a transactional behavior to enable the Encryption Server (0051) to be accessed for "secure 
transactions (0051)" so that the eService delivery can be completed properly and securely. 
Therefore, it would have been obvious to modify Negri's eSM tool to specify a completion 
requirement contract specifying transactional behavior in the eService model (0050) to help 
complete transaction, i.e. inter-company transactions (0051). 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 
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For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
/Insun Kang/ 

Primary Examiner, Art Unit 2193 
Conferees: 

/Lewis A. Bullock, Jr./ 

Supervisory Patent Examiner, Art Unit 2193 

/Wei Y Zhen/ 

Supervisory Patent Examiner, Art Unit 2191 



